[Bug] Fix four CI workflow defects: laptop-only path, unscoped pytest, unbounded test job, py3.9 release build (#1798) - #1812

Hello there, thank you for opening an PR ! 🙏🏻 The team was notified and they will get back to you asap.

Correction to this PR's body, found while reading fresh CI logs on #1815.

I wrote that scoping pytest via testpaths = ["tests"] makes the Python package job correct and therefore that python-package.yml needs no edit. That is wrong about the outcome. The job's actual failure is:

ERROR collecting examples/guides/850_workshop/test_agent_concurrent.py
E   ModuleNotFoundError: No module named 'swarms'

python-package.yml:31-33 installs flake8, pytest and requirements.txt, but never installs the package under test:

        python -m pip install --upgrade pip
        python -m pip install flake8 pytest
        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi

So testpaths does fix what defect 2 describes, collecting examples/ and scripts/, but the job stays red regardless, because tests/ imports swarms too and swarms is not installed. My table showing that fix should not be read as "this job goes green".

The missing line is one more in the same step:

         if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
+        pip install -e .

I have not pushed that, since it is a fifth change and this PR was already scoped to the four in #1798. Say the word and I will add it here, or send it separately. Everything else in the PR stands as written.

Rebased onto f894187d and added the fifth defect — the one I flagged in the comment above but had not actually fixed.

python-package.yml installs flake8, pytest and requirements.txt, but never installs the package under test, so import swarms fails and the job dies at collection on all three Python versions. testpaths = ["tests"] in this PR stops it collecting examples/, but tests/ imports swarms too, so scoping alone was never going to be enough. One line:

        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
        # The tests import swarms, so the package under test has to be installed.
        python -m pip install -e . --no-deps

--no-deps because the line above it already installed requirements.txt; without it pip re-resolves the full dependency set for no benefit.

Verified in a clean 3.12 venv, mirroring the job's ordering:

$ python -m pip install -e . --no-deps
Successfully installed swarms-14.0.0
$ python -c "import importlib.util as u; print(u.find_spec('swarms') is not None)"
True

python-dotenv and the rest of the runtime imports come from requirements.txt:8, which the job already installs, so --no-deps does not leave a gap.

All five defects re-confirmed present on f894187d before pushing:

Master's own latest run on f894187d is red on Run Tests, Test Main Features, Python package, Pyre — Lint is green now that #1814 and #1817 have landed. This PR is aimed at the second and third of those.

CI result on this push, which is the first time this workflow has actually reached its tests.

Before: the job died at step 7, Install dependencies, on poetry install --with test --no-dev — Poetry 2.x dropped --no-dev. Nothing downstream ever ran.

Now (run 31302007581):

##[group]Run poetry install --only main,test        <- installs cleanly
...
Test Summary: 14/18 passed (77.8%)

So the two defects this PR targets in that workflow are confirmed fixed against real CI: the install step completes, and the removed cd /Users/swarms_wd/Desktop/research/swarms no longer aborts the run step on a hosted runner.

The job is still red, and it is worth being precise about why — it is not this PR, and it is not something this PR claims to fix. All remaining failures are one cause:

litellm.exceptions.InternalServerError: OpenAIException - Missing credentials.
Please pass an `api_key` ... or set the `OPENAI_API_KEY` environment variable.

That string appears 1472 times in the log. The failing tests are test_basic_agent_functionality, test_agent_with_custom_prompt, test_multi_agent_router and one more in the same summary — every one of them constructs an Agent and calls a live model. test-main-features.yml has an Set up environment variables step but no OPENAI_API_KEY secret behind it, so the 4 tests that need a real key cannot pass on any branch.

That is a fifth, separate defect: either the secret needs configuring on the repo, or those 4 tests need to skip when no key is present. I have deliberately not folded it into this PR — the first is a repo-settings change only a maintainer can make, and the second changes test semantics rather than CI plumbing. Happy to open it as its own PR if you would like the skip-guard; say the word and I will.

For this PR the claim is narrower and now evidenced: the workflow goes from never executing to executing and reporting 14/18.

Build-job result, and one more line pushed.

The package-install fix works. All three matrix legs now report:

build (3.10)  Install dependencies  Successfully installed swarms-14.0.0
build (3.11)  Install dependencies  Successfully installed swarms-14.0.0
build (3.12)  Install dependencies  Successfully installed swarms-14.0.0

No ModuleNotFoundError: No module named 'swarms' on any leg, and testpaths = ["tests"] is doing its job — pytest collects 1797 items from tests/ and no longer walks examples/.

But the job is still red, for a new reason that only became visible once it got this far. It runs to 29% and then stops emitting for fifteen minutes:

07:50:50  tests/structs/test_aop.py .........FF..F.FF.F..FF..FF.F.FF.F.FF...F.F.F. [ 29%]
08:05:34  ....FF..F..F..
08:05:34  ##[error]Process completed with exit code 143.

Exit 143 is SIGTERM — the runner killed it. tests/structs/test_aop.py hangs, and python-package.yml had no timeout-minutes, so the job sat there burning a runner until the platform reaped it.

That is the same defect this PR already fixes in tests.yml (defect 3, unbounded test job), just in the workflow next door — I fixed one and missed the other. Pushed the matching line:

   build:
     runs-on: ubuntu-latest
+    timeout-minutes: 20
     strategy:
       fail-fast: false

To be clear about what this does and does not buy: it does not turn the job green. It makes it fail in a bounded, legible way instead of hanging for 17 minutes, which is the whole point of the defect.

The test_aop.py hang itself is a real, separate bug — it is not CI plumbing, it is a test that blocks (AOP binds a server and does network work). It is also the likeliest reason the test job in tests.yml has been unreliable. I have not touched it here; this PR is scoped to workflow configuration, and diagnosing a hanging server test belongs in its own change. Happy to take it as a follow-up if you want it.

Net for this PR: five workflow defects fixed, all five re-confirmed present on f894187d, and two of them now evidenced by CI going from never executing to executing — test-main-features reports 14/18, and Python package installs and collects 1797 tests.

Rebased onto current master so this is clean against HEAD.

Flagging the blast radius, since this has been sitting a little while and reads like minor cleanup. The build (3.x) job is failing on master itself, not just on PRs. Last five runs of python-package.yml on master:

aa81316e -> failure
a3f7a6e8 -> failure
47d94eba -> failure
2616a62a -> failure
707ebc0c -> failure

The cause is the thing this PR fixes. The job installs flake8 pytest plus requirements.txt, but nothing installs swarms itself, and there is no testpaths, so bare pytest walks the whole repo and every module that does import swarms fails at collection. Current run reports 106 errors during collection, all ModuleNotFoundError: No module named 'swarms'.

The unscoped collection has a second edge to it: examples/ gets walked too, and a few of those build an Agent(...) at module level, so collection alone would try to construct agents before a single test runs. That is the same class of problem as #1809.

So build (3.10 / 3.11 / 3.12) has not been able to go green for anyone, on any PR, for as long as those runs go back. The two lines that fix it are pip install -e . --no-deps and testpaths = ["tests"].

Happy to split the release-workflow and timeout bits into their own PR if you would rather review the pytest fix on its own, just say the word.

apologize if i missed something obvious here, i traced it from the failing job logs and checked master's own run history to be sure it wasn't just my branch. freshman in college, still learning my way around CI, so corrections very welcome :)

Rebased on today's master. Bumping this one because it is the reason every other PR in the repo shows red, and I can now point at the exact failure.

Master's own Python package run this morning (31969068025, commit 3ff34758):

collected 167 items / 106 errors
ERROR collecting examples/guides/850_workshop/test_agent_concurrent.py
E   ModuleNotFoundError: No module named 'swarms'
ERROR collecting examples/guides/aop_examples/discovery/test_aop_discovery.py
E   ModuleNotFoundError: No module named 'swarms'
... 106 of these

Two separate defects produce that, and this PR fixes both:

1. pytest collects examples/. There is no testpaths, so a bare pytest from the repo root walks every test_*.py under examples/ — files that are demos, not tests. testpaths = ["tests"] scopes it.
2. The package under test is never installed. The job installs requirements.txt but not swarms itself, so every collected module fails on import swarms. pip install -e . --no-deps fixes it.

Measured locally on master vs this branch, running exactly what CI runs:

master:      2019 tests collected, 14 errors in 14.95s   (interrupted)
this branch: 1779 tests collected,  0 errors in  1.73s

Locally only 14 example files error because my venv has swarms installed; on the runner it is all 106. Both counts go to zero with this change.

The other two hunks are the same class of thing:

• test-main-features.yml runs cd /Users/swarms_wd/Desktop/research/swarms before the test command — someone's laptop path, which cannot exist on a runner. That is why Test Main Features is red, independently of the above.
• RELEASE.yml builds on Python 3.9, which pyproject.toml no longer supports.

Nothing here touches library code — five workflow/config lines. Worth landing ahead of my other PRs, since right now a green signal is impossible for any of them and the failures are indistinguishable from real ones.